perm filename LISP.MSC[RDG,DBL] blob
sn#631759 filedate 1981-12-17 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00007 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Date: 5 Sep 1979 2044-PDT
C00022 00003 ∂TO MRC 11:25 19-Oct
C00025 00004 ∂26-Oct-81 1106 Russell Greiner <GREINER at RAND-AI> Small question, with big dribble file:
C00049 00005 ∂TO MASINTER@PARC (CC CSD.SMITH) 13:35 15-Jul
C00066 00006 ∂TO MASINTER@PARC 13:46 2-Oct
C00077 00007 ∂17-Dec-81 1658 Masinter at PARC-MAXC New version of Interlisp-10 (release 145)
C00097 ENDMK
C⊗;
Date: 5 Sep 1979 2044-PDT
From: CSD.GREINER
Subject: Trouble with SCORE
To: admin.mrc
cc: csd.greiner, csd.dea, csd.lenat
Mark,
When running (Inter)LISP on SCORE I've three times fell victim to the
following bug:
During a MAKEFILE, in which LISP writes out a file, SCORE issues a
DISK QUOTA EXCEEDED interrupt. After EXPunging, and CONTinuing, I examined
the file just created, and discover a very obnoxious thing have happened --
various bits of the source code appears duplicated at a random place, creating
all sorts of havoc when I later try to read this file in.
Should this happen? How can I avoid it?
Thanks.
Russ
-------
22-Oct-79 21:38:54-PDT,00000897;000000000001
Date: 22 Oct 1979 2138-PDT
From: CSD.DEA
Subject: Re: ↑E
To: CSD.GREINER
cc: CSD.LENAT
In-Reply-To: Your message of 22-Oct-79 1714-PDT
Russ,
I think I know what is happening, but I can't say exactly why.
It appears as though LISP was running through some critical process
during which it turned all interrupts off. It does this occasionally,
for example, during garbage collections. It is my conjecture that the
stack overflow occurred during one of these critical processes, and
in its confusion, failed to return the interrupts to their previous
state. I noticed that doing the KillU(Cost) a second time resulted in
a stack overflow during a different point in the computation, but
didn't result in interrupts being disabled.
If you have trouble with this again in the future, you can
get things back to normal by typing INTERRUPTABLE(T).
- Doug
-------
24-Oct-79 09:28:51-PDT,0000000333;000000000001
Date: 24 Oct 1979 0226-PDT
From: Admin.MRC
Subject: quota exceeded interrupt
To: CSD.DEA
Remailed-date: 24 Oct 1979 0928-PDT
Remailed-from: CSD.DEA
Remailed-to: CSD.GREINER
This bug MAY be fixed. At least I could not reproduce it in one trivial
test case. If you can verify this for me I'd be grateful.
Mark
-------
25-Jan-80 15:38:41-PST,00000000410;000000000001
Date: 25 Jan 1980 1538-PST
From: CSD.DEA
Subject: LISP file - JFN bug
To: csd.greiner
Russ,
I've tried to reproduce the problem you suffered the other
evening without success. If it ever happens again, please
tell me exactly what you did to cause it in as much detail as
possible. If you have time, you might try reproducing it
yourself with your own files. Thanks.
- Doug
-------
22-Jan-80 23:07:32-PST,00000923;000000000001
Date: 22 Jan 1980 2307-PST
From: CSD.GREINER
Subject: Lets switch to Fortran ...
To: csd.lenat
cc: csd.greiner
Found a bug with INTERLISP: The dribble file is handled specially, DEA informs
me. That is why the fix which prevents LISP from clobbering files when a
QUOTA exceeded error occurs, doesn't apply to the situation of when such
an error occurs when a DRIBBLE file is open - such as when you are almost out
of space, and more junk is being spewed into that dribble file. When that
happens, after you do the standard expunge, you will note the JFN which
had pointed to your dribbefile is no longer pointing to anything. As LISP
checks that there is such a file, trouble...
I managed to find a solution to this problem, from KDO@SAIL; and
will send you a copy of that procedure.
To my amazement, DEA conceeds this is LISP's fault. I rather enjoyed
those infinite circular pointers.
Russ
-------
6-Mar-80 23:20:28-PST,0001184;000000000001
Date: 6 Mar 1980 2320-PST
From: CSD.GREINER
Subject: Oye...
To: lenat at SUMEX-AIM, csd.smith
cc: csd.greiner
I can't seem to shake that bug... I talked with Doug Appelt, who told me
there is already a known bug in this version of LISP, which smashes atoms
(eg sets their pnames to be pages in length, and their plists to things like
0...). Apparently this might happen at any arbitrary time, after one types
a ↑D or ↑E. Possibly our problem is related. (All three times I tried it,
with COMPILED code, I got that clobberage. The one time it seemed to be
working, when I used INTERPRETED code, I got into some infinite FIXSPELL
loop - probably due to the same bug.)
Dave: Is there some reason typing ?? to CORLL only returns the
last 3 instructions? What happened to 1,2 & 3?
Based on DEA's warning, we should henceforth avoid
any extraneous control characters, esp when making SYSOUTs.
Doug: I almost forgot the good-ish news - RLL is back to its old
self now - Diagnose gave it a clear bill of health (after I repaired it).
See you tomorrow, at about 10. DEA says he'll be in then as well, providing
an additional shoulder to cry on...
Russ
-------
7-Mar-80 00:00:20-PST,00001564;000000000001
Date: 7 Mar 1980 0000-PST
From: CSD.GREINER
Subject: Aha, another scheme that doesn't work!
To: lenat at SUMEX-AIM, csd.smith
cc: csd.greiner
Well, DEA valiantly recovered an older version of LISP (#132), and I tried
that. (The CORLL & RLL .EXE's on <CSD.LENAT> are using this OLD:LISP.)
You'll be pleased to note I didn't get the same error I got using the newer
version... I got a different one. (The STACK OVERFLOW message is repeated
endlessly.)
I tried, on the older CORLL (on the newer LISP, that is) using the
interpreted code for FNewUnit and InitializeUnit; and found LISP wouldn't let
me replace the compiled versions of these with their source code. Arghhh!
CORLL, by the way, is (of course) totally innocent -- there were no <control>
whathaveyous in it.
Doug: Dave noted REMOVE calls itself RECURSIVELY - so that stack overflow
may be due simply to having that many stack frames - one for each member
of some 350+ elements of the list (plus however many frames were there from
earlier- when UP-BUMPUNITS was called.)
So that problem may have an easy solution: Just by rewriting our version of
DREMOVAL (D for Destructive, AL for equAL) ITERATIVELY (I know it hurts, Doug)
rather than recursively this problem may simply vanish.
If only that other one was so congenial...
[Also: DEA assures me the problem is NOT due to some GLOBAL variable being
locally bound, as happens to some of the variables in that call (but not
the ones which get #777777 for their pname, or NOBIND for their value.)]
Ciou, Russ
-------
9-May-80 20:53:56-PDT,000001001;000000000001
Date: 9 May 1980 2053-PDT
From: CSD.GREINER
Subject: Report
To: CSD.LENAT
cc: csd.greiner, CSD.SMITH
Well, everything seems to work. USEME is all set to go...
I was forced into a ↑D during an earlier session (I subsequently
closed the KBs, and the current USEME was after reloading everything
into CORLL,...): I got into the LISP editor`s TYPE-AHEAD mode, thanks to
LISP "help" in correcting what a mistyped word. Normally one can exit that
by typing <esc>STOP, however the terminal I was using gobbled up the <esc>,
so I found myself trapped. I even tried using another terminal,
with the same result. (If that happens again, I'll try TELNETting to that
job, and see if that keeps the <esc> for LISP. Is there some way you know
of "QUOTING" a character, to get it thru?)
Oh, doing that CLOSE I found the diagnosing function accounted for everything
up to 415864 -- any idea what happened to the fimiliar 1000...00100?
Abida-abida-abida ... that`s all folks!
Russ
-------
4-Mar-81 13:15:58-PST,0000992;000000000001
Date: 4 Mar 1981 1315-PST
From: CSD.GREINER
Subject: The author of LISP.EXE
To: csd.dea
cc: csd.greiner
is CSD.FREEMAN - observe:
[PHOTO: Recording initiated Wed 4-Mar-81 12:54PM]
[Link from CSD.GREINER, TTY121]
TOPS-20 Command processor 5(665)-4
@WD <LISP>LISP*
PS:<LISP>
PGS Write Creator Writer
LISPHACKERS.DIS.50 1 7-Dec-80 16:30:46 CSD.DEA CSD.DEA
LISP.EXE.133 599 18-Sep-80 17:28:17 CSD.FREEMAN CSD.FREEMAN
.136 600 18-Sep-80 11:15:08 ADMIN.MRC ADMIN.MRC
LISPMSG.TXT.1 1 8-Oct-79 11:06:00 CSD.DEA CSD.DEA
LISPFEATURES.TXT.1 16 9-Sep-79 17:21:24 CSD.DEA CSD.DEA
Total of 1217 pages in 5 files
@PO
[PHOTO: Recording terminated Wed 4-Mar-81 12:55PM]
(That was the only file on <LISP> note created and written by
either MRC or DEA, by the way.)
Russ
[Also, a reminder about the bug in the LISP<=>EMACS document --
it no longer shows ↑T Z...]
-------
5-Mar-81 09:56:43-PST,0000000779;000000000001
Date: 5 Mar 1981 0956-PST
From: CSD.DEA (Doug Appelt)
Subject: Sysout - Makesys lossage
To: CSD.GREINER
Russ,
If you were making your sysouts on the most recent version (136)
then the problem is not with the "mysterious" MAKESYS that was written by
someone else. If <LISP>LISP.EXE.136 is the MAKESYS you were using
(you get it by typing LISP to the exec without any qualifiers) then
the problem was caused by something else. Do you have a SYSOUT that
suffers from this difficulty that I can poke around with? Also, does
it happen in a sysout that you create just after loading files without
hacking around in it for a long time before making it -- i.e. is
the problem readily repoducible? If so, I'll turn in a bug report on it.
- Doug
-------
10-Mar-81 13:54:25-PST,0000000276;000000000001
Date: 10 Mar 1981 1354-PST
From: CSD.GREINER
Subject: A Damaged Sysout
To: csd.dea
cc: csd.greiner, csd.smith
is now sitting in <CSD.IA>RUSS.EXE. (It was created as <CSD.LENAT>RUSS.EXE,
while I was connected <CSD.RLL>, if that makes any difference.)
Russ
-------
10-Mar-81 14:28:55-PST,0000000714;000000000001
Date: 10 Mar 1981 1428-PST
From: CSD.DEA (Doug Appelt)
Subject: Makesys bug
To: CSD.GREINER
Russ,
After looking at the sysout, it appears that there was quite
a bit of hacking going on before the SYSOUT and after the startup.
It would be interesting to know where the clobberage is taking
place. Do you have any idea when it happens, for example, if you
start up a bare lisp and load the RLL files and do a sysout
immediately, does the sysout still work?
As for unadvising, there is no standard way to remove selected
pieces of advice. The only suggestion I have would be to write
some calls to the editor to search specifically for before and after
advice, etc.
- Doug
-------
9-Jan-81 10:57:47-PST,00000001470;000000000001
Date: 9 Jan 1981 1057-PST
From: CSD.SMITH
Subject: [Vanmelle@SUMEX-AIM: Re: Help!]
To: CSD.GREINER, CSD.LENAT
cc: csd.clayton
Mail-from: ARPANET site SUMEX-AIM rcvd at 9-Jan-81 1040-PST
Date: 9 Jan 1981 1035-PST
From: Vanmelle@SUMEX-AIM
Subject: Re: Help!
To: CSD.SMITH@SU-SCORE
In response to your message sent 8 Jan 1981 1718-PST
Somewhere between the time you start the good sysout and the bad sysout is
made, someone is smashing the low-core locations that contain the name of
the parent makesys, <LISP>LISP.EXE.whatever. When a sysout is started,
that is the first thing that is looked up, and quite naturally no
interrupt char will work then, since Lisp isn't running yet.
Needless to say, someone has a nasty bug. All I can suggest is to narrow
the window on the bug, fom trying to do a sysout without doing ANYTHING,
to making it with as little loaded as possible, etc. If it's just
one file, see if bug happens with comparable compiled files. Seee if
it happens in some "cleaner" sysout. Sigh.
Bill
-------
---------------
Doug Appelt looked at the problem, and found that if you respond with <LISP>
LISP.EXE to the prompt NEW MAKESYS NAME:, the sysout works ok, and thereafter
loads ok also. This doesn't tell us what clobbered it in th first place, but
at least allows me to get one working for the moment. Just a bit of folklore
in the event that it ever happens to you!
Dave.
-------
18-Mar-81 13:12:39-PST,0000248;000000000001
Date: 18 Mar 1981 1312-PST
From: CSD.GREINER
Subject: SYSOUT Problem
To: CSD.DEA
cc: CSD.GREINER, CSD.LENAT
Doug (Appelt) -
Check the sysout <CSD.LENAT>RUSS.EXE (protection = 777777).
I copied it into <3SCRATCH> as well.
Russ
-------
14-Jul-81 23:07:46-PDT,607;000000000001
Mail-from: ARPANET site PARC-MAXC rcvd at 14-Jul-81 2307-PDT
Date: 14 JUL 1981 2307-PDT
From: MASINTER at PARC-MAXC
Subject: SETSYNTAX
To: CSD.DEA at SU-SCORE
cc: csd.greiner at SU-SCORE, Masinter
If you read something in and then prettyprint it out and you
get something different from what you read, then there are
two places to look for the bug:
Either the readmacro is wrong, and you didn't read in what
you thought,
or else, the PRETTYPRINTMACRO is wrong, and you didn't write
out the right thing.
Please try to help Russ on this one (you are the site liason,
no?)
Larry
-------
∂TO MRC 11:25 19-Oct
Final Rand Notes
Thanks for your help the other day. Unfortunately something was wedged --
either LISP or TOPS20, or more likely, some interaction between the two.
(Otherwise how could a total of two users drive the load average to over
6...)
Anyway - FYI:
the EXEC SAVE command does NOT work on LISP images -- something
about the lower part not being saved.
(I lost big using that command -- not only didn't it work, but it destroyed
my image, guaranteeing my lossage... oh well.)
(Fortunately I do have a trace file -- all 90 pages. Damn these computers
anyway.)
When the user DETaches his job, that job does NOT get killed after
half an hour. As you suspected, that rule is only when something like the
TIP abandons the job. (Moral to me: I should just have detached at the time.)
Finally - you may want to fix your plan files, on both SAIL and Rand-Ai.
Both list your old home phone (which does get forwarded to your new number,
by the way).
Back to work -- maybe, just maybe, I'll catch up to where I was yesterday.
Russ
∂19-Oct-81 1444 Mark Crispin <Admin.MRC at SU-SCORE> Re: Final Rand Notes
Subject: Re: Final Rand Notes
To: RDG at SU-AI
In-Reply-To: Your message of 19-Oct-81 1125-PDT
Yeah, the SAVE command can't win with INTERLISP; it runs in two forks.
Sigh.
-------
∂26-Oct-81 1106 Russell Greiner <GREINER at RAND-AI> Small question, with big dribble file:
To: masinter at PARC-MAXC
cc: rdg at SU-AI, wescourt at RAND-AI
Larry -
Another LISP problem, this time dealing with RECOMPILE. Can you
explain it, or at least tell me what I should do if/when it happens again?
Summary: when MAKEFILE is recompiling a function, after doing the actual
LAP code generating work, it "forgets" the name of the file in which to write
this function, causing OPNJFN to break. Note this only seems to happen after
a garbage collection; and I should comment that INTERRUPT is adviced here,
with a(n interpretted) function. I did check: that function does NOT even set
any U variable -- it, in fact, is a no-op in this situation.
A shortened version of the DRIBBLE file taken from this episode follows.
(That full file is [Rand-Ai]<GREINER>TRACE.OCT25. And this entire
episode occurred on Rand-Ai, of course.)
-----
21←MAKEFILE(RLL (RC STF]
RLL will be written on GREINER.RLL.
Am proceeding.
compiling <GREINER.RLL>RLL..39
listing? STF
NumTimes, PerformAction,
(DeSingle (x) NIL)
collecting lists
3709, 3709 free cells, 22 pages left
(GetRangeApply (rng1 input-rngs) NIL)
GetVerifier, AptSlot, SimpleWriteKB, SingleArgOf, InverseTuple,
... --- here dozens of fns were either copied or compiled, uneventfully --- ...
UnitsEffectedA0037, UnitsEffected, WhereInitFn,
collecting lists
3825, 3825 free cells, 22 pages left
(AllExamplesRangeFn (rng) NIL)
... --- here dozens of fns were either copied or compiled, uneventfully --- ...
DefaultActualPutValue,
collecting lists
3934, 3934 free cells, 22 pages left
DefaultActualSubstValue, DefaultAddValue, DefaultAfterGetValue,
... --- here dozens of fns were either copied or compiled, uneventfully --- ...(InvalidateEach (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
3641, 3641 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
(ComposingUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
2611, 2611 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
FILE NOT OPEN
NIL
(OPNJFN broken)
22:?=
U = NIL
V = NIL
23:BT
OPNJFN
RANDACCESSP
*LAPST*
*PROG*LAM
*LAP*
LAPBLOCK
LAP
*PROG*LAM
COMPILE2
*PROG*LAM
COMPILE1
*PROG*LAM
*PROG*LAM
*PROG*LAM
ERRORSET
*PROG*LAM
BRECOMPILE
RECOMPILE
MAKEFILE1
*PROG*LAM
MAKEFILEB0006
*PROG*LAM
ADV-PROG
ADV-SETQ
*PROG*LAM
ADV-PROG
MAKEFILE
**TOP**
24:EXEC
131075
25:BT
OPNJFN
... --- same as above --- ...
**TOP**
26:BTFN COMPILE2
-- a BT-like BREAKMACRO --
DEF [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(* edited: "25-Oct-81 14:05")
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(PROG
(temp (hold NIL)
(sc (CAR fullHLD)))
(DECLARE (LOCALVARS temp sc)
(SPECVARS hold))
(RETURN
(SELECTQ
gen-p
(Gen
(MergeUpdates
affectedslt
[SUBSETC
(REVERSE (CDR fullHLD))
(FUNCTION
(LAMBDA
(slt)
(DECLARE (LOCALVARS slt))
(PROG
(morework pmet)
(DECLARE (LOCALVARS morework
--- ↑Eed - but this is a regular function... ---
(OPNJFN broken)
27:REEVAL COMPILE2 T
--- BREAKMACRO which reevaluates that occurance of COMPILE2.
--- the "T" means to break the function as well.
(COMPILE2 broken)
28:?=
FN = ComposingUpdating
DEF = [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(* edited: "25-Oct-81 14:05")
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(PROG
(temp (hold NIL)
(sc (CAR fullHLD)))
(DECLARE (LOCALVARS temp sc)
(SPECVARS hold))
(RETURN
(SELECTQ
gen-p
(Gen
(MergeUpdates
--- ↑Eed again ---
(COMPILE2 broken)
29:ARGLIST(COMPILE2]
(FN DEF)
30:eval
collecting lists
2451, 2451 free cells, 22 pages left
(ComposingUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
2718, 2718 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
COMPILE2 evaluated
31:value
ComposingUpdating
32:ok
COMPILE2
(COMPILE2 broken)
32:?=
FN = ApplyUpdating
DEF = [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(* edited: "25-Oct-81 14:08")
(PROG
(hold temp)
(DECLARE (LOCALVARS hold temp))
(RETURN
(SELECTQ
gen-p
(COMPILE2 broken)
33:eval
(ApplyUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
3181, 3181 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
FILE NOT OPEN
NIL
(OPNJFN broken)
34:?=
U = NIL
V = NIL
35:BT
OPNJFN
RANDACCESSP
*LAPST*
*PROG*LAM
*LAP*
LAPBLOCK
LAP
*PROG*LAM
COMPILE2B0074
**BREAK**
COMPILE2
*PROG*LAM
COMPILE1
*PROG*LAM
*PROG*LAM
*PROG*LAM
ERRORSET
*PROG*LAM
BRECOMPILE
RECOMPILE
MAKEFILE1
*PROG*LAM
MAKEFILEB0006
*PROG*LAM
ADV-PROG
ADV-SETQ
*PROG*LAM
ADV-PROG
MAKEFILE
**TOP**
36:BTV
OPNJFN
RANDACCESSP
FN ApplyUpdating
*LAPST*
BNDLEV 0
AC2 T
AC1 T
AC7 NIL
TAGACS ((26 T)
(25 T)
(24 T)
(23 T)
(22 T)
(21 T)
(20 T)
(19 T)
(18 T)
(17 T)
(16 T)
(15 gen-p)
(27 T)
(14 T)
(13 T)
(12 T)
(11 T)
(10 T)
(9 T)
(8 T)
(7 T)
(6 T)
(5 gen-p))
JFLG T
ETAGS NIL
VVP 12
VPP 14
GTAGS ((26 . 296)
(25 . 295)
(24 . 265)
(23 . 244)
(22 . 276)
(21 . 277)
(20 . 176)
(19 . 158)
(18 . 157)
(17 . 137)
(16 . 136)
(OPNJFN broken)
37:↑
(COMPILE2 broken)
37:eval
(ApplyUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
3311, 3311 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
FILE NOT OPEN
NIL
(OPNJFN broken)
38:BT
OPNJFN
RANDACCESSP
*LAPST*
*PROG*LAM
*LAP*
LAPBLOCK
LAP
*PROG*LAM
COMPILE2B0074
**BREAK**
COMPILE2
*PROG*LAM
COMPILE1
*PROG*LAM
*PROG*LAM
*PROG*LAM
ERRORSET
*PROG*LAM
BRECOMPILE
RECOMPILE
MAKEFILE1
*PROG*LAM
MAKEFILEB0006
*PROG*LAM
ADV-PROG
ADV-SETQ
*PROG*LAM
ADV-PROG
MAKEFILE
**TOP**
39:
(OPNJFN broken)
39:BTV
OPNJFN
RANDACCESSP
FN ApplyUpdating
*LAPST*
BNDLEV 0
AC2 T
AC1 T
AC7 NIL
TAGACS ((26 T)
(25 T)
(24 T)
(23 T)
(22 T)
(21 T)
(20 T)
(19 T)
(18 T)
(17 T)
(16 T)
(15 gen-p)
(27 T)
(14 T)
(13 T)
(12 T)
(11 T)
(10 T)
(9 T)
(8 T)
(7 T)
(6 T)
(5 gen-p))
JFLG T
ETAGS NIL
VVP 12
VPP 14
GTAGS ((26 . 296)
(25 . 295)
(24 . 265)
(23 . 244)
(22 . 276)
(21 . 277)
(20 . 176)
(19 . 158)
(18 . 157)
(17 . 137)
(16 . 136)
(15 . 301)
(27 . URET2)
(14 . 114)
(13 . 113)
(12 . 94)
(11 . 95)
(10 . 69)
(9 . 45)
(8 . 44)
(7 . 24)
(6 . 23)
(5 . 119)
(-1 . 3))
UTAGS ((LITORG . 308)
(PLITORG . 308))
IUTAGS ((LITORG . 308)
(PLITORG . 308))
BACKAST NIL
LST NIL
AST ((affectedslt . 1)
(fullHLD . 2)
(changedslt . 3)
(argnames . 4)
(gen-p . 5))
LOC 363
LITN NIL
LIT ((affectedslt . 1)
(fullHLD . 1)
(changedslt . 1)
(argnames . 1)
(gen-p . 1)
Gen Flatten MEMB "In " ApplyUpdating " -- " 1 "." Warning UpdateASUIB
"In "
" -- " 2 "." InvalidateInverseFn "In " " -- " 3 "." "In " " -- " 4 "."
APPEND MergeUpdates P "In " " -- " 5 "." InvalidateFromHLD
((un oth) . 0)
HLDefnExpander x tst1 ListFormat ((QUOTE +CHECK-APTNESS) . 0)
GetGetVal LAMBDA FUNCTION SOME ((QUOTE +CHECK-APTNESS) . 0)
InvalidateP "In " " -- " 6 "." "What is " "? In " ".")
UDFTGS (NIL NIL)
*PROG*LAM
FREE NIL
FN ApplyUpdating
*LAP*
LAPBLOCK
FREE NIL
FN ApplyUpdating
LAP
FATALERROR NIL
BNDLEV 1
SBNDLEV 0
TAGNUM 27
NLGOFLUSH NIL
GENUSES NIL
BLKFLG NIL
ARGTY 0
FREE NIL
ARGS (affectedslt fullHLD changedslt argnames gen-p)
CODE NIL
SPECVARS T
LOCALVARS (affectedslt fullHLD changedslt argnames gen-p $$1 $$2 $$3 $$4 $$5
$$6 $$7 $$8 $$9 $$10 $$11 $$12 $$13 $$14 $$15 $$16
$$17 $$VAL $$TEM $$TEM1 $$TEM2 $$LST1 $$LST2 $$LST3
$$LST4 $$LST5 $$LST6 $$END)
OTHERVARS NIL
*PROG*LAM
DEF [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(* edited: "25-Oct-81 14:08")
(PROG
(hold temp)
(DECLARE (LOCALVARS hold temp))
(RETURN
(SELECTQ
gen-p
(Gen (MergeUpdates affectedslt
(APPEND (COND ((MEMB changedslt
(Flatten (CADR fullHLD)))
(Warning "In " (QUOTE
ApplyUpdating)
(OPNJFN broken)
40:↑
(COMPILE2 broken)
40:
(COMPILE2 broken)
40:OPENP]
(<GREINER.RLL>RLL..39 <GREINER.RLL>BCOMPL.SCRATCH.2 <GREINER.RLL>RLL.COM.12
<GREINER.RLL>RLL.COM.11)
41:EXEC
131075
42:BREAK(OPNJFN]
(OPNJFN)
43:?=
FN = ApplyUpdating
DEF = [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(* edited: "25-Oct-81 14:08")
(PROG
(hold temp)
(DECLARE (LOCALVARS hold temp))
(RETURN
(SELECTQ
gen-p
(Gen (MergeUpdates affectedslt
(APPEND (COND ((MEMB changedslt
(COMPILE2 broken)
44:eval
(ApplyUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting lists
4783, 4783 free cells, 22 pages left
collecting arrays
553, 553 free cells, 22 pages left
(OPNJFN broken)
*** Am re-opening Dribble file: <GREINER.RLL>TRACE.OCT25.1 [25-Oct-81 16:54:22
]
45:?=
U = NIL
V = NIL
46:BT
OPNJFN
RANDACCESSP
*LAPST*
*PROG*LAM
*LAP*
LAPBLOCK
LAP
*PROG*LAM
COMPILE2B0074
**BREAK**
COMPILE2
*PROG*LAM
COMPILE1
*PROG*LAM
*PROG*LAM
*PROG*LAM
ERRORSET
*PROG*LAM
BRECOMPILE
RECOMPILE
MAKEFILE1
*PROG*LAM
MAKEFILEB0006
*PROG*LAM
ADV-PROG
ADV-SETQ
*PROG*LAM
ADV-PROG
MAKEFILE
**TOP**
47:
(OPNJFN broken)
47:↑
(COMPILE2 broken)
47:GAINSPACE]
purge history lists ? Everything
discard definitions on property lists ? no
discard old values of variables ? yes
erase properties ? no
erase CLISP translations ? no
discard context of last edit ? yes
erase filepkg information ? no
discard FFILEPOS initialization ? no
deallocate PMAP buffers ? yes
mapatoms called to erase the indicated properties...done
48:eval
(ApplyUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting arrays
560, 560 free cells, 23 pages left
(OPNJFN broken)
49:?=
U = <GREINER.RLL>RLL.COM.12
V = NIL
50:eval
OPNJFN evaluated
51:value
8
52:ok
OPNJFN
COMPILE2 evaluated
52:ok
COMPILE2
(COMPILE2 broken)
52:?=
FN = OrderingUpdating
DEF = [LAMBDA
(affectedslt fullHLD changedslt argnames gen-p)
(* edited: "25-Oct-81 14:05")
(DECLARE (LOCALVARS affectedslt fullHLD changedslt argnames gen-p))
(PROG
(hold alter)
(DECLARE (LOCALVARS hold alter))
(RETURN
(SELECTQ
gen-p
(Gen (MergeUpdates affectedslt
(APPEND (COND ((MEMB changedslt
(COMPILE2 broken)
53:eval
(OrderingUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
collecting arrays
560, 560 free cells, 23 pages left
(OPNJFN broken)
54:?=
U = <GREINER.RLL>RLL.COM.12
V = NIL
55:ok
OPNJFN
COMPILE2 evaluated
56:ok
COMPILE2
(COMPILE2 broken)
56:ub
(COMPILE2)
57:ok
(TransitiveUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
(OPNJFN broken)
58:?=
U = <GREINER.RLL>RLL.COM.12
V = NIL
59:ok
OPNJFN
COMPILE2
(DefaultFnForUpdating (affectedslt fullHLD changedslt argnames gen-p) NIL)
(OPNJFN broken)
60:?=
U = <GREINER.RLL>RLL.COM.12
V = NIL
61:UB
(OPNJFN)
62:ok
OPNJFN
(DoToEach (effectedslt invHLD argnames) NIL)
(GetVals (effectedslt invSLOT argnames) NIL)
collecting arrays
474, 986 free cells, 22 pages left
(InvalidateFromHLD (hld args affectedslt sub?) NIL)
(MergeUpdates (affectdst updatelist gen-p) NIL)
(UpdateASUIB (affectdst hld changslt args gen-p) NIL)
<GREINER.RLL>RLL.COM.12
<GREINER.RLL>RLL..39
63←FILES?]
OLD,UTIL,PROP,XUTILM,CORLL...to be dumped.
RLL,FIELD...to be listed.
NIL
------
... I'll spare you the rest. This error occurred again when
re-compiling UTIL - another big file.
Any ideas?
Russ
-------
∂27-Oct-81 1559 Masinter at PARC-MAXC Re: Small question, with big dribble file:
To: Russell Greiner <GREINER at RAND-AI>
cc: masinter, Lewis@BBND, Yonke@BBND, rdg at SU-AI, wescourt at RAND-AI
Sounds like a problem when recompiling with a generated sub-function. One
thing you can do for (us) to debug this is to take ComposingUpdating and put it
on a separate file. See if you can make it break when recompiling that file. If so,
see how much of ComposingUpdating you can gut and still have it fail.
Larry
∂TO MASINTER@PARC (CC CSD.SMITH) 13:35 15-Jul
Wow - such fast response!
Larry:
Some comments on your comments:
0) Did you peruse both XUTIL and XUTILM. Both have nice goodies Dave and
I have assembled -- often after finding that both of us (and no doubt other
users as well) had independently written isomorphic code for the same
type of task.
By the way, I assume you are aware of Bill vanMelle's goldmine, in WW.
1) our friend BACKQUOTE
We have four flavors of the beast:
(BACKQUOTE form vals fn) - evaluates all three args. Any occurance of ,1 in
(the evaluation of) form is replaced by (CAR vals), ,2 is replaced
by (CAR (NTH vals 2)), etc. (IE the value of (CAR (NTH vals i)) replaces
each ,i -- and the value is spliced in for ",@i"s)
Of course the usual ,expr is evaluated, as happens in all variants
of backquotes.
Now for other bells and whistles:
i) Maybe you didn't really want to EVALuate the ,expr occurring within
form - but really wanted to hand this to some arbitrary function.
It is the value of that function call which is then
CONSed (or APPENDed) into the unevaluated surrounding parts of
the overall expression.
This arbitrary function is the third argument passed, which
defaults to EVAL if omitted...
Note it's a bit confusing what to do with ,1 type of things in this case.
As vals is already evaluated, there is no easy way to first
unevaluate its CAR, and then apply fn to that value.
So what we do is use the value of (APPLY* fn (CAR (NTH vals i))).
In practice, I never use both vals and fn. (Actually, I never
bother to use vals.)
ii) It turns out I needed to have nested BACKQUOTEs -- which means I wanted
the outer form to return things which still had ,s in them.
Hence the ,'expr -- which expands to ,expr.
(BACKQUOTEQ form vals fn) - Just like BACKQUOTE, but leaves form unevaluated.
(BACKQUOTE* form val1 val2 ... valN) - This is similar to BACKQUOTE, but here each
,i is replaced with vali, rather than that (CAR (NTH vals i)).
Note one cannot use the optional function here.
(BACKQUOTEQ* form val1 val2 ... valN) - This has evolved to be the standard
form. It is just like BACKQUOTE*, except that form is passed unevaluated.
There is also a macro for this last BACKQUOTEQ* form, which expands into the
desired set of CONSes and APPENDs. As a fringe benefit, it will only
evaluate the ,1 ... once -- so
(BACKQUOTEQ* (,1 ,1) (GENSYM))
expands into
((LAMBDA (A1) (LIST A1 A1))
(GENSYM))
and NOT
(LIST (GENSYM) (GENSYM))
[Note one can still get that latter form by typing
(BACKQUOTEQ* (,(GENSYM) ,(GENSYM)))
]
I agree with you - having a , readmacro would be a win -- especially when PPing
the forms. [Seeing things like
(BACKQUOTEQ* (foo fred
,
(CAR dog)))
is very annoying.]
I didn't know about such read- and pp- macros when I was (re)writing
those functions.
You may have noticed a great deal of the complexity of these functions
(well, of BACKQUOTEL and BQFN, the unseen workhorses for these schenanigans)
is in handling both
,dog
and
, (CAR frog)
-- which had to be done independently.
Is the solution to have ,dog to expand to (UNBQ dog), ,@dog into (UNBQ @ dog)?
I think this would obviate the need to have the ,'dog things - yes?
Anyway, perhaps someone with time could fix up the code -- I will if I get
the chance; eventually...
2) I'm the culprit responsible for the DRIBBLE stuff.
It seems the dribble file isn't closed when the system crashes -- and hence
it is lost those times you need it most.
So it hacked up the stuff in DRIBBLECOMS, which essentially re-opens the
dribblefile every 25 user commands. (That constant is the value of some variable
whose name I forget.)
Anyway, I since added a bunch of other user DRIBBLE related stuff -
like the advise to LOGOUT which closes the file, and on the various
____SYSOUTFORMS.
Doing this I realized some other incompletenesses of IL: eg that it was
impossible to selectively unadvise a function. Hence that function.
3) The -DO macros basically simulate what the MACLISP DO function does.
The various flavors indicate how precise (and expensive) the match is.
EG the plain -DO doesn't worry about evaluating the forms at once.
4) What is "NIH"? (Noway In Hell was proposed, and National Institute of Health
was quickly rejected.)
5) Yes - your PSETQ* was obscure. In what way is it more efficient that
Dave's code?
6) By the way, the file [Rand-Ai]<GREINER.RLL>UTIL has other potentially useful
general goodies, intermingled with many specific-to-my-task functions.
For example, I'm queried where to keep each function as soon as it is created,
thanks to advice to /PUTD, /MOVD and friends.
Let me know if you want to be burdened with those "features".
Thanks,
Russ
∂15-Jul-81 1531 Masinter at PARC-MAXC Re: Wow - such fast response!
In-reply-to: RDG's message of 15 Jul 1981 1335-PDT
To: Russell Greiner <RDG at SU-AI>
cc: masinter, csd.smith at SU-SCORE
(1) I wanted an example where all of the hair in BACKQUOTE was useful.
Given the amount of cruft already in Interlisp, I'm reluctant to add a lot of hair
to a facility if a hairless version is as useful in 90% of the cases. Your answer
leads me to believe that the simpler one I did (which I intend to include in the
"standard" release) is in fact useful in 90% of the cases.
(2) Why don't you hook in your DRIBBLEFILE stuff into the IOWAITDAEMON?
Better than some arbitrary count on events.
(3) you still didn't answer why you didn't use the iteratives which are already
there... Do you dislike them, or just the documentation? (I'm thinking about the
next revision to the manual)
(4) NIH = Not Invented Here: the major reason for reimplementing something that
was already done by somebody else....
(5) Perhaps I didn't understand the way that PSETQ* translated, but it seemed
like my version would not do any conses while Dave's code would, every time
you did an assignment.
(6) The "right" way to handle querying where to put a function as soon as it is
created is to hook in a WHENCHANGED property for the filepackagetype (cf. p
14.73.) E.g. (FILEPKGTYPE 'FNS 'WHENCHANGED '(FINDPLACEFORITEM))
and (FINDPLACEFORITEM (NAME TYPE NEWFLG)
(if (NOT (WHEREIS NAME TYPE)) then (FILES?)]
About packages in general: people are free to put packages with documentation,
on the <NetLispUsers> directory at PARC (login ANONYMOUS yourname). A
general "utility" file isn't really appropriate, but rather something which can be
separately documented and or loaded is. vanMelle has been reluctant to publish
his stuff, because he doesn't want folks to bug him, I guess. (I don't want folks
to bug him too much, either, I suppose.) Do you want folks to bug you?
Larry
∂TO MASINTER@Parc, CSD.SMITH@Score 16:06 20-Jul
Additional comments:
1) I certainly hope the LISP compilers do NOT do the "optimization" the
APPLY* macro does. Consider what happens to
(APPLY* 'Foo Fred),
when Foo is a regular SUBR -- ie it will go to
(Foo Fred).
Ahh, but now the wily coder changes his mind, and realizes it should be
an NLAMBDA -- ie that the first argument should not be evaluated. However
it's the value of Fred, not the atom "Fred" itself, which should have been
passed in the example above. Need I go on?
2) You were right about DSETQ* -- your version definately saves those
cons-cells. I was thinking about an earlier version Dave and I discussed
which took another argument - which was a list - and reused those cells.
That, apparently, was never implemented. Sorry about the confusion.
3)wrt BACKQUOTE:
Yes, I agree there is no reason to have the additional arguments
for ,1 and the like -- that was just because that approach seemed easier;
and (without knowing about PPMacros) this seemed to print out prettier.
However, there are a few places where the other arg -- that arbitrary function
bit, was quite useful.
The file HEURS (ie {Rand-Ai}<GREINER.RLL>HEURS and now on {SAIL}HEURS[1,rdg])
uses that argument, via BACKQUOTEFN - an earlier incarnation of BACKQUOTE.
One relevant function is DefaultCodeGen, shown below
(DefaultCodeGen
[LAMBDA (phrase args)
(* edited: " 5-Mar-81 13:50")
(PROG (temp)
(RETURN (COND
((ATOM phrase)
phrase)
((SETQ temp (CodeGeneratingFn (CAR phrase)))
(APPLY* temp (CDR phrase)
(QUOTE DefaultCodeGen)
args))
[(GETD (SETQ temp (CAR phrase)))
|||| HERE |||| (BACKQUOTEFN phrase
|||| HERE |||| (FUNCTION (LAMBDA (term)
(DefaultCodeGen term args]
((Processp temp)
(APPLY* (GetValue temp (QUOTE LispFn)
(QUOTE (VERYSAFESLOT VERYSAFEUNIT)))
phrase
(QUOTE DefaultCodeGen)
args))
(T (Warning "Unable to figure the code to generate from " phrase
". (In "
(QUOTE DefaultCodeGen)
".)"])
Although it may not be obvious, this function will return essentially
the value of its first argument, phrase. Only certain key parts of this
s-expression need to be examined; the rest is simply returned as is.
Sounds like BACKQUOTE, don't it?
(Haven't you ever wanted to do something like this?)
Only here I want to "evaluate" that expression by recurring the
DefaultCodeGen call, rather than use BQ's EVAL.
So do I really have to duplicate all the code in BACKQUOTE to get this effect;
or do something silly like temporarily redefining the EVAL function, or ...
Anyway, the above code is a real example -- not just something kludged up to
attempt to convince you.
Should you buy this idea, it's not clear to me how you would want to print
out that stuff above.
Perhaps you would want to leave accessible the function which BQUOTE called,
which did take both arguments. This would allow us users to write our own
BQ-ish functions, which did or didn't evaluate various args, ...
4) Thanks for your suggestions about IOWAITDEMONs, and the like. It is
nice having so knowledgable a LISP wizard so close by.
.
5) Sure, if there's a bug in my code, or some obvious extension I hadn't
yet thought of, I'd like for people to tell me.
When else would people assault me, if my various pieces of code are released?
Thanks,
Russ
∂TO MASINTER@PARC 13:46 2-Oct
InterLisp Queries
Larry -
I've a few questions, related to InterLisp, (as you might have guessed).
First: I noted that neither PUTD nor /PUTD (nor MOVD, /MOVD) call
MARKASCHANGED. Is this a feature, or a bug? You may remember I went
through the hassle of advising these functions, (as well as a slew of others)
to help with my bookkeepping; then abandoned these when you told me the
FILEPKGTYPE(FNS WHENCHANGED (...)) hack would solve these problems.
Turns out it doesn't.
Next: Is there any way I can enter LISP which does NOT read (and execute)
the INIT.LISP file on my login directory? (Short of first renaming that file?)
I know I can then UNDO that GREET command, but I feel guilty making
LISP do all that work for naught.
[A particular problem motivated this question:
The FILE package never finds out about the files which are LOADed
during this start-up, rendering these files next to impossible to alter.
I tried simply tacking the names of these files onto FILELST.
This makes the functions on these files "readonly" -- EDITF will now read
in these files, but a subsequent MAKFILE begins by (re)reading in the
file, wiping out the changes.
The only way I know of altering these files is to first LOAD them by hand.
Certainly there must be a better way...]
I've been burned a few times when I edited a broken functions -- for indirect
reasons, sometimes these changes go away when I later unbreak the function;
and other times I get a funny message when the function executes, because
the BREAK1 calls seems to remain.
Anyway, I thought it might make sense to have EDITF consider first unbreaking
the function, (ie only if the user approves), and then rebreaking it after
editing.
I thought advising EDITF would dod the trick. That, however, fails:
the UNBREAK command is aborted with a message that this function is now being
edited. So now the question: How does it know? And how can I circumvent
it, permitting me to unbreak that function?
My final question is about Rand-Ai's <LISP>LISP.EXE.133 in particular.
There are a lot of bells and whistles present in SCORE's version which are
not included there -- such as the LISPXMACROS
EV, EP, EF, and CONN. Will subsequent releases of Lisp include these
niceties; or will these only be customizations?
---
Hope these pesky questions aren't too bothersome -- but, in each case,
I couldn't find anything in the manual which helped, nor did any
of the locals have any suggestios.
Thanks,
Russ
∂02-Oct-81 1448 Masinter at PARC-MAXC Re: InterLisp Queries
To: Russell Greiner <RDG at SU-AI>
cc: masinter
∂TO MASINTER@PARC 15:40 2-Oct
Thanks. Rebuttal:
** Thanks for your rapid comments. My suggestions/requests for clarifications/
** volunteered information/etc appear below, prefaced by **s.
The decision about which things call MARKASCHANGED is heuristic. If you are
defining functions and want the file package to know about it, you need to call
DEFINE or else do the MARKASCHANGED explicitly. Any place in the SYSTEM
which defines functions (e.g. MAKEFN macro or COPYDEF or MOVD from top
level or DEFINE, etc.) do wind up doing a MARKASCHANGED.
** NO - it was a top level MOVD not calling my WHENCHANGED function
** that alerted me to this problem.
** (Perhaps it was because MOVD was advised?)
** Anyway, I reentered my advise to do that MARKASCHANGED.
** It still is a hassle figuring that, for example,
** what LOAD or ADVISE generates is not really changed,
** but that any thing produced by a MOVD is. Oh well, ...
At PARC our <LISP>INIT.LISP has a hack in it where if you typed LISP<lf>
rather than LISP<cr> it won't do the user's GREET.
** It would be nice if
** LISP;foo<cr>
** read in the file foo.
** (I often want to read in the INIT.LISP from my CONNECTed directory,
** rather than my login directory. Typing
** LISP;INIT.LISP<cr>
** would do that.)
** For "upwards compatibilty", the file <login-dir>INIT.LISP should
** be read in if both the file name and the ";" were omitted.
** To read in nothing, type
** LISP;<cr>
** (I imagine this would come for almost nothing -- thanks to the
** errorset around the load, and the fact that few users have a file
** names NIL, or "", or whatever the transmitted name would end up
** being.)
I don't see what is wrong with doing a LOADFROM on the files you want to
edit if they are loaded by GREET. It may be a hassle, but having the files be
"real" turned out to be more of a hassle more often. Please don't just tack them
onto FILELST! The results are unpredictable...
** Oh, does LOADFROM really do the right thing here? I'll confess I
** never tried it -- figuring it was aleady being done each time
** I called EDITF on those functions; and realizing that that didn't
** work anyway.
There is some complicated mechanism in the EDITF-BREAK interaction which is
"supposed" to work reasonably. If you have an example where it doesn't I'd like
to see it and try to fix the interaction.
** Is this your saying you don't know why BREAK wouldn't break any
** function now being edited, either?
** Anyway, next time I get clobbered I'll let you know. As I mentioned
** it's usually because some (BREAK1 ...) carcass which isn't cleaned up.
Appelt or someone hacked up something so that the LISP.EXE at SCORE was
really a SYSOUT into which a lot of packages had already been loaded. I imagine
one could do the same thing at RAND-AI. If you find out what was done, let me
know and I will let other sites know about it.
** Yes - I plowed thru that when trying to move these things to
** Rand-Ai a few months ago. He has a function which spits out a
** INIT.LISP file, which is then read in when initializing LISP.
** Check the files
** INIT.LISP and MAKEINIT.LSP, both on [SCORE]<LISP>.
Larry
(p.s. Are you SCORE's new Interlisp liason? I heard Appelt had quit....)
** Actually he used words like "Graduated" - but I see you weren't fooled...
** No - I personally wouldn't mind; but Doug (Lenat) would be annoyed
** to see me spending such time on non-thesis things.
** New material:
When Keith noted that <LISP>LISP.EXE and <SUBSYS>LISP.EXE were identical, and
each occupying about 600 pages, he changed <SUBSYS>LISP.EXE into a (3 page)
system "macro", which simply goes to <LISP>LISP.EXE.. It seems to work, so far.
I just wanted to ask if this is safe, in general.
Thanks again,
Russ
∂17-Dec-81 1658 Masinter at PARC-MAXC New version of Interlisp-10 (release 145)
To: "@InterlispSites.dl"
This message announces a new version of Interlisp-10, version 145.
This version is available to Arpanet sites as:
[PARC-MAXC]<LISP>NETLISP.SAV;145.
Please forward as appropriate to your users.
(Xerox users will find a version on <SUBSYS>LISP.SAV;145.)
Sources and .COM files are also found on [PARC-MAXC]<LISP>.
Note that we have discontinued using PARC-specific .COM files, so that
the need for a separate NETLISP and NETLISPUSERS directories have
vanished. You should once again obtain all files from <LISP> and
<LISPUSERS>, although <NETLISP>MESSAGE.TXT may be of some interest.)
This release includes a number of important bug fixes and
improvements, as well as support for features to enable Interlisp
programs to be written so that they may be more easily ported to
other implementations of Interlisp (specifically, Interlisp-D,
Interlisp-Jericho and Interlisp-VAX.)
Note that most of these changes are not specific to Interlisp-10;
they appear in Interlisp-D, -Jericho and -Vax.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(SYSTEMTYPE) [Function]
The function (SYSTEMTYPE) is defined in all implementations to
return the type of the currently running system. In Interlisp-10,
it returns either the atom TOPS20 or TENEX. Programs which need to
perform different actions depending on the type of system they are
running under can write
(SELECTQ (SYSTEMTYPE)
((TENEX TOPS20) (* Interlisp-10 version) --)
(VAX (* Interlisp-VAX version) --)
((D ALTO) (* Interlisp-D version) --)
(JERICHO (* Interlisp-Jericho version) --)
--)
All Interlisp compilers, including Interlisp-10, will actually
perform the selection at compile-time (for the "target" system.)
This means that, although the selection looks like it is run-time,
it is actually handled at compile time.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(COMPILEMODE) [Function]
The function (COMPILEMODE) is defined in all implementations to
return the type of the system being compiled for. This differs from
(SYSTEMTYPE) in that one can perform cross-compilation, e.g., run
the Interlisp-D compiler under Interlisp-VAX. Note also that
(COMPILEMODE) for Interlisp-10 is the atom PDP-10, rather than
TENEX and/or TOPS20.
This sometimes occurs, e.g., in the fileCOMS for a file, for
example:
(DECLARE: EVAL@COMPILEWHEN (EQ (COMPILEMODE) (QUOTE PDP-10))
(FILES (SYSLOAD FROM VALUEOF LISPUSERSDIRECTORIES)
CJSYS]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10MACRO [Property]
MACRO [Property]
VAXMACRO [Property]
DMACRO (ALTOMACRO) [Property]
JMACRO [Property]
COMPILERMACROPROPS [Variable]
Another way of conditionally compiling for different systems is to
use different macro properties. The Interlisp-10 compiler (and
other Interlisp compilers) now search for a number of properties
(as determined by the variable COMPILERMACROPROPS) rather than a
single one. The property MACRO should be reserved for
machine-independent macros. If you have macros which are specific
for a single implementation (e.g., Interlisp-10 macros which
generate ASSEMBLE code), you should use the
implementation-dependent macro name. In Interlisp-10, this is the
atom 10MACRO.
The packages EXPANDMACRO, MACROTRAN, ASSEMBLETRAN have all been
modified to be compatible with this change.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(LINELENGTH N FILE) [Function]
The notion of line length is now file-specific. Every file has its
own individual line length. The linelength for T is set from the
operating system via the function (SETLINELENGTH) {executed at
every (RESET) and when starting an Interlisp-10 sysout}. The line
length for disk files is initially set to be the value of
FILELINELENGTH when a file is opened for output.
This change was motivated primarily by multiple-window systems
where each window wants to have its own notion of the length of a
line, but is definitely an improvement in the semantics of
LINELENGTH. Unfortunately, it is necessary to examine existing uses
of the function LINELENGTH to ensure that they will continue to
operate correctly. Since the FILE to LINELENGTH, if unsupplied,
defaults to the current output file, most existing uses of
LINELENGTH will continue to work unchanged.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(ARRAY SIZE TYPE INIT) [Function]
The ARRAY function in Interlisp-10 has been extended to accept a
TYPE argument as allowable in other Interlisp implementations. In
particular, TYPE can be any "specification" which is allowable in a
datatype declaration:
(BITS n)
POINTER
FIXP
FLOATP
There are not actually any new array types in Interlisp-10; that
is, the ARRAY function returns an array which will "hold" the
values specified. This allows code to be written which takes
advantage of the new features of the other Interlisp
implementations but will still run in Interlisp-10.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(DEFPRINT TYPENAME FUNCTION) [Function]
The interpretation of DEFPRINT function has been extended
(compatibly) so that the user's function gets passed a second
argument, FILE. If output is being directied to a file, the full
name of the file will be passed. (If output is for one of the
internal printing functions, e.g., NCHARS, the FILE argument will
be NIL.) The value returned from the users DEFPRINT function is
interpreted as follows:
NIL - print the standard #nnnnn for this object
a list - If the car is non-NIL, print it using PRIN1. Then, if
the CDR is non-NIL, print it using PRIN2.
(The non-NIL CDR test is a change. It means the
user doesn't have to return (PACK) to avoid
PRIN2 printing.]
anything else - no additional printing (beyond what the user
function did) is performed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(ECHOCONTROL CHAR MODE) [Function]
The function ECHOCONTROL returns and will accept as its MODE
argument the atom INDICATE (instead of UPARROW) to mean "indicate
the character as appropriate". This change was made in order to
handle reasonably the printing of characters in extended ranges,
namely, the 8-bit character codes in other Interlisp
implementations.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(SKIPSEPRS FILE RDTBL) [Function]
Advances the file pointer of FILE until a non-SEPR character in RDTBL is
peeked at. Value is that non-sepr, or NIL if there are no non-seprs left on the
file.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BREAKCHECK and NLSETQ interaction
We have fixed the interaction with NLSETQ and BREAK so that it is
guaranteed that no break will occur (unless HELPFLAG is !BREAK) and
no error message will be printed (unless NLSETQGAG is NIL) under an
NLSETQ.
This change removes the necessity of re-binding HELPFLAG to ensure
this behavior, e.g., (RESETVARS (HELPFLAG) (RETURN (NLSETQ --] can
be re-written back as (NLSETQ --].
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(FINDFILE FILE NSFLG DIRS) [Function]
The FINDFILE function has been modified slightly. If the DIRS
argument is supplied, FINDFILE will no longer first look on the
connected directory. The connected directory will be searched if and when the
atom T is found in the list. NIL in the DIRS-list still means the "login"
directory. (Note: FINDFILE is a "super" INFILEP; it attempts
spelling correction, unless NSFLG is T, and will scan the given
DIRS or the directories on the global variable DIRECTORIES.
This mechanism may be used in lieu of or in addition to the
directory-path feature of TOPS-20; many system packages when
scanning for files use FINDFILE or its SPELLFILE equivalent.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Font profile change
The entries on the variable FONTPROFILE no longer need the "extra
cell" documented in the manual.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New (versions of) LISPUSERS packages, on [PARC-MAXC]<LISPUSERS>
Site maintainers should check to see if they have the latest versions of the
following LISPUSERS packages. Unfortunately, some of the version numbers have
been reset, so that the most reliable way of checking is to look at the
FILECREATED date, or at least the creation-date of the file on our <LISPUSERS>
directory. Files recently updated or released include:
BQUOTE (new package, see .TTY file), DECL, PERFORMTRAN (new package),
ALL, COMMENT, REMIND
All other packages have been recompiled using a somewhat improved PDP-10
compiler; it is probably also worth retrieving new .COM files for all packages.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GREET implementation change
GREET no longer uses the GREETDIRECTORY/GREETFILE/GREETEXT
mechanism to determine the "name" of t~e greet file. Instead, GREET calls
a single function, GREETFILENAME, which can be advised or redefined if the
user wants to modify the behavior of GREET.
(GREETFILENAME USER) is called twice, once with USER=T and once with
USER=USERNAME. In the standard system, (GREETFILENAME T) returns
<LISP>INIT.LISP, while (GREETFILENAME 'user) returns <user>INIT.LISP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FNS/VARS file
Unfortunately, there is no FNS/VARS file for this loadup of Interlisp-10.
We will attempt to provide a cross reference file in the near future.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special loadups
For those sites which make special loadups, please be advised that the
"filegroups" (PRETTY COMMENT), (EDIT WEDIT), (DWIMIFY WTFIX CLISP)
have been split up. If you were formerly explicity loading (or excluding)
PRETTY.COM, you will have to explicitly load (or exclude) both PRETTY.COM
and COMMENT.COM to have the same effect.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Various fixes:
LOADCOMP? remembers more reasonably which files have been
LOADCOMPed. Many minor fixes to the file package, break package,
clispify, record.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A few reported bugs have not been fixed yet:
(EXPT 16.0 16) still returns wrong result (Interlisp-10 only).
Masterscope cannot analyze expressions beginning with "with".
does not see field names used in conjunction with change-words.
SHOW PATHS has problems with extremely long function names.
If there are other bugs which have been reported and have not been fixed,
please remind us.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Compiler
This version of Interlisp-10 contains an improved compiler. In particular,
the compiler performs some "constant-folding". For example, simple numeric
expressions consisting only of constants will be computed at compile time.
This is particularly useful in expressions which get generated via macros.
[These optimizations are also performed by the Interlisp-D (and thus -VAX)
compilers and, I believe, the Interlisp-Jericho compiler.]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(CONSTANTS . vars) [File package command]
The user can now declare variables as constants (in all Interlisp
implementations). The file package command (and function) CONSTANTS
resembles the VARS file package command in format, but the value
of the variable will actually be used in-line in the code generated by
the compiler. This allows users to declare variables as compile-time-constants
without having to explicitly wrap a CONSTANT around its use.
This feature should be used with some caution, since functions must
which use a constant must be recompiled when the value of the constant
changes. If there is a Masterscope data base of the users functions, Masterscope
will warn the user about which functions need recompilation when a
CONSTANT is reassigned at the top level.
------------------------------------------------------------